home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / tsql / doc / tsql.mail / 000040_csj@iesd.auc.dk _Tue Mar 16 23:39:48 1993.msg < prev    next >
Internet Message Format  |  1996-01-31  |  7KB
  1. Received: from iesd.auc.dk by optima.cs.arizona.edu (5.65c/15) via SMTP
  2.     id AA27274; Tue, 16 Mar 1993 15:39:32 MST
  3. Received: from yellow.iesd.auc.dk by iesd.auc.dk with SMTP id AA07007
  4.   (5.65c8/IDA-1.5/MD for <tsql@cs.arizona.edu>); Tue, 16 Mar 1993 23:39:48 +0100
  5. Date: Tue, 16 Mar 1993 23:39:48 +0100
  6. From: "Christian S. Jensen" <csj@iesd.auc.dk>
  7. Message-Id: <199303162239.AA07007@iesd.auc.dk>
  8. To: tsql@cs.arizona.edu
  9. Subject: Re: Benchmark initiative
  10.  
  11. Jim, Al, and Alex,
  12.  
  13. I hope you all survived the worst snow storm in 100 years :-)
  14.  
  15. Thanks for your interest in the TSQL Benchmark. I have read your
  16. posting to the tsql list with great interest. I agree with your
  17. observations, and I thank you for taking the time to communicate them.
  18.  
  19. Let me now attempt to address your concerns within the context of the
  20. benchmark effort. Some of your concerns can be met now, and the rest
  21. may need to await a later edition of the benchmark.
  22.  
  23. >From info-tsql-sender@cs.arizona.edu Tue Mar 16 20:42:45 1993
  24. >
  25. >We would like to make two comments on the proposal to develop a
  26. >comprehensive set of natural language queries as a test of "goodness"
  27. >of various query languages and algebras.
  28.  
  29. In the initial proposal for a database schema for the benchmark (sent
  30. to tsql a few days ago), I included this characterization (based on
  31. Rick's postings to the tsql list).
  32.  
  33. "The central goal of this document is to provide the temporal database
  34. community with a {\em comprehensive consensus benchmark} for temporal
  35. query languages which is {\em independent} of any existing language
  36. proposal.
  37.  
  38. This is not a performance benchmark, but a {\em semantic} benchmark
  39. which is intended to be an aid in evaluating the user-friendliness of
  40. proposals for temporal query languages. Thus, temporal query languages
  41. should ideally be able to express the benchmark queries both
  42. conveniently and naturally."
  43.  
  44. To me, the key word is user-friendliness. The benchmark is intended to
  45. be a valuable tool for designers of user-level query languages in
  46. general and of a TSQL language, in particular. The benchmark is not
  47. intended to cover algebras which are not user-level languages. Using
  48. the benchmark, a designer may become aware of boolean seams (Shashi
  49. has shown the importance of avoiding these), of violations of the
  50. 0-1-infinity principle, of lack of orthogonality, of other types of
  51. inconsistencies (see the PL literature), etc.
  52.  
  53. >First, we feel that a certain classification of various queries has to
  54. >be established before the set of queries is proposed.  As an *initial*
  55. >suggestion, we can classify temporal queries as follows.
  56. >
  57. >         | HISTORICAL     | ROLLBACK  | BITEMPORAL
  58. >--------------------------------------------------------
  59. >UNGROUPED     |        |        |
  60. >         |        |        |
  61. >GROUPED         |        |        |
  62. >         |        |        |
  63. >TEMP. AGGREGATES |        |        |
  64. >         |        |        |
  65. >SCHEMA VERSIONING|        |        |
  66. >         |        |        |
  67. >OTHER FEATURES     |        |        |
  68. >--------------------------------------------------------
  69. >
  70. >Then we can place one or several queries in each cell of this matrix.
  71.  
  72. I think you are exactly right that a classification (or taxonomy) is
  73. needed before queries should be proposed. That was what I tried to
  74. indicate in the introductory statement of the schema proposal and in
  75. the plan that accompanied the schema proposal.
  76.  
  77. "% The purpose of the following draft is then to define a taxonomy to
  78. % be used for categorizing the benchmark queries that will follow."
  79.  
  80. "Three tasks must be accomplished initially.
  81.  
  82. Task 1: Agree on a database schema.
  83. Task 2: Agree on an instance of the schema.
  84. Task 3: Agree on a suitable taxonomy for the benchmark queries.
  85.  
  86. These tasks will be addressed sequentially during the next weeks. When
  87. they are completed, the benchmark will be populated with queries."
  88.  
  89. I think your taxonomy is very helpful. It is very much a top-down
  90. taxonomy that makes it possible to classify a very wide variety of
  91. queries.
  92.  
  93. In order for the current version of the benchmark to not become too
  94. big (I would not like it to exceed, say, 100 queries), Rick suggested
  95. a restricted scope. Thus, only valid time is addressed, and aggregates
  96. as well as schema versioning are presently not addressed. As a
  97. result, most queries in the initial benchmark will fall into only a
  98. couple of categories, making additional refinement desirable.
  99.  
  100. I will request the help of you, Shashi, Ed, Patrick, Fabio, Maria,
  101. Paolo, and Abdullah (among others) when Task 3 is addressed. Grouping
  102. will certainly be an important aspect of this taxonomy and of the
  103. queries themselves, and I hope that you will be able to help ensure
  104. that it is present.
  105.  
  106. >The second comment is that the development of the benchmark should not
  107. >be a substitute for a rigorous *theoretical* study of expressive
  108. >powers of various temporal query languages and algebras.  It is not
  109. >entirely clear what the goal of the benchmark is.  What seems
  110. >necessary is a kind of typography of temporal data models as suggested
  111. >by the above table and discussion.  For example, one data model can be
  112. >grouped bitemporal, another be ungrouped historical with aggregates.
  113.  
  114. I will emphasize in the introduction of the schema proposal document
  115. that the benchmark is not intended to be such a substitute. 
  116.  
  117. The current formulation is:
  118.  
  119. "While the benchmark is not intended to constitute a metric for query
  120. language completeness, ..."
  121.  
  122. I will change the formulation to this:
  123.  
  124. "The benchmark is {\em not} intended to constitute a metric for query
  125. language completeness, and as such it is not a substitute for a
  126. rigorous {\em theoretical} study of expressive powers of various
  127. temporal query languages."
  128.  
  129. Making a stronger and more explicit point out of this is very
  130. appropriate. I hoped that the introduction would have explained what
  131. was the goal of the benchmark. I will gratefully accept additional
  132. clarifications, to be added to the document.
  133.  
  134. >Perhaps, the benchmark can be useful in developing such a typography.
  135. >Each type of data model should support a class of queries the model
  136. >embodies and should have its own standard of completeness.  We believe
  137. >that this standard should be developed in the terms of an appropriate
  138. >logic (as in the classical relational case) rather than trying to
  139. >determine expressive power "by consensus" (we would not want to say
  140. >that one language is more expressive than another if it can express
  141. >95% of the benchmark queries and the other one only 87%).
  142.  
  143. This is again an important point! I have seen papers argue that one
  144. algebra is better than another algebra because the former satisfies
  145. more criteria (from the Comp Surveys paper by Rick and Ed M) than the
  146. latter. That is very unfortunate. Similarly, we must try to avoid this
  147. use of the benchmark. For now, I'll add the following text to the
  148. introduction. This text may have to be refined later on.
  149.  
  150. "It it emphasized that using the benchmark as an advanced,
  151. quantitative scoring system for comparing languages makes little
  152. sense. Thus, one language is not necesarily superior to another just
  153. because one is capable of expressing more benchmark queries than the
  154. other. Rather, the focus is on user-friendliness."
  155.  
  156. Best regards,
  157. Christian